A service is a system that a consumer of the service interacts with through a set of coarse-grained messages. A service oriented application may be composed of one or more services. Each of these application services typically contains a set of entities. Entities, in general, encapsulate data and provide a rich programming model for reading, writing, updating and deleting the data owned by the service.
Services typically contain private data and public data. The private data is encapsulated in an internal entity so that, within the service, the programming model provides access to all of the data and associations contained in the internal entity, but external to the service, the internal entity is not exposed through the service interface. However, public data is encapsulated in a publicly available entity which is available to consumers of the service.
Services also typically expose a plurality of publicly available data contracts. The data contracts identify the publicly available entities and the properties contained within those entities and specify how the entities are associated or related. Upon being queried through an interface, the service will generally provide access to data in the publicly available data contracts to the requestor.
It is common for a consumer of a service to access data of an entity owned by the service. One prior way for enabling this had the consumer directly access the owning service's data store. However, a direct access to the owning service's data store requires the consumer of the data to have knowledge of the technology and table structure used by the owning service to store data in its data store. Similarly, such direct access allows the consumer to potentially view and change private data within the service. This is problematic for a number of reasons, and is discouraged in applications that honor the publicly known tenets of service orientation. These are set out in an article by Don Box entitled Code Name Indigo: A Guide to Developing and Running Connected Systems with Indigo, MSDN Magazine, January 2004. Basically, allowing an external service or client to bind directly to the owning service's data (either by access to the service's private entities or by directly accessing the data store which the service stores its data in) is a technique that compromises data integrity, the autonomy, and the explicit boundaries of the service in a service oriented environment. Instead, all communication between services should use standardized message exchange.
In addition, to comply with the aforementioned tenets developers must develop systems in which the services are autonomous. Synchronizing and replicating data locally to the consumers of the service is often done to achieve such autonomy. This allows for the owning service to not have to be online to retrieve data and process requests.
Traditionally, clients that are communicating with other services utilize Extensible Mark-up Language (XML) directly, or generated proxy classes without encapsulated business logic. This causes the clients to employ a more batch oriented, less interactive user experience. A more interactive experience would provide a mechanism for the client to ensure that the data provided is correct for the owning service, that the data is transmitted in the correct manner, and even allow data to be defaulted, or auto-populated, as the user interacts with the client application.
However some developers of clients have attempted to manually build this interactive user experience. For clients that do support a more interactive user experience, the developers find themselves writing large amounts of logic on the client to support this interactivity. Further, clients typically need to supply a URI or URL which represents the physical location of the destination service. They need to supply the protocol they wish to communicate to the service with. They also need to manage the creation of communication channels and other intricacies of communicating with a service. Most often, the developer of the client does not understand the necessary logic to provide the rich interactive experience to the user. However, the entity author of the owning service generally understands the logic necessary to provide the interactive experience.